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This  paper  examines  the  state  of  the  Army’s  information  technology  (IT) 
acquisition  workforce,  in  light  of  the  push  for  outsourcing.  It  then  makes 
recommendations  to  improve  the  workforce. 

For  the  last  few  decades,  a  variety  of  market  forces  and  government  initiatives 
have  pushed  the  Army  to  outsource  IT  system  development.  From  having  entire  units  of 
government  programmers  and  hardware  engineers,  the  Army  has  steadily  moved  toward 
outsourcing — using  commercial  industry  to  design  and  build  its  IT  solutions. 

But  at  the  same  time  the  Anny  has  moved  away  from  designing  and  building  its 
own  IT  systems,  IT  has  become  more  prevalent  and  pervasive  within  the  Army.  It  has 
become  even  more  critical  to  Anny  success  in  the  field.  Almost  every  Army  system 
fielded  today  contains  some  sort  of  computer  system.  In  this  era  of  net-centric  warfare, 
these  computer  systems  are  expected  to  share  information  with  each  other  securely  and 
efficiently.  It  is  these  interconnections  that  have  helped  the  Army  fight  and  win  in  recent 
wars. 

There  is  mounting  evidence  in  the  military,  the  federal  government,  and  private 
industry  that  too  much  outsourcing  can  be  a  bad  thing.  It  can  leave  an  organization 
without  the  talent  needed  to  oversee  the  outsourced  work,  and  eliminate  a  career  ladder 
that  allows  Anny  IT  leaders  to  leam  their  trade  before  making  multi-million  dollar 
procurement  decisions.  Congress  has  realized  this  in  the  last  few  years,  and  is  beginning 
to  push  the  armed  services  to  strengthen  their  control  over  IT  outsourcing  efforts. 

This  paper  makes  the  case  for  the  uniqueness  of  IT  acquisition  as  compared  to  the 
acquisition  of  non-IT  products  and  for  the  need  of  skilled  and  experienced  Anny  IT 

iii 


acquisition  professionals  and  leaders  to  oversee  the  contractors  and  ensure  quality  results. 
It  analyzes  the  current  Army  IT  acquisition  workforce  along  with  current  Army  and  DoD 
policy.  From  this  analysis,  it  detennines  that  there  is  much  confusion  over  the  exact 
duties  that  the  IT  Acquisition  Workforce  should  be  perfonning,  there  is  no  single  entity 
responsible  for  shaping  and  developing  the  workforce,  there  is  inadequate  technical 
education  and  training,  and  finally  that  there  is  a  lack  of  hands-on  development 
experience  that  would  help  in  overseeing  the  commercial  contractors  doing  the  work. 

The  paper  offers  several  recommendations  to  strengthen  the  Army’s  IT 
acquisition  workforce  including:  detennining  the  specific  duties  and  responsibilities  of 
the  IT  Acquisition  Professional,  centrally  managing  the  entire  workforce,  fonnalizing  a 
mid-career  hiring  program,  creating  a  non-management  technical  track,  and  keeping 
some  technical  work  in-house  to  train  government  personnel  so  that  they  can  better 
understand  and  oversee  contractor’s  technical  efforts. 
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SHAPING  THE  ARMY’S  INFORMATION  TECHNOLOGY 
ACQUISITION  WORKFORCE  IN  AN  ERA  OF  OUTSOURCING 

Introduction 

During  the  last  few  decades,  the  Anny  has  steadily  divested  itself  of  information 
technology  (IT)  development  expertise  in  favor  of  outsourcing — letting  contractors  build 
the  Army’s  systems.  The  Army  acquisition  workforce’s  job  is  to  oversee  this  work  and 
ensure  that  the  Anny  gets  the  quality  IT  systems  it  needs,  on  time  and  within  budget. 
However,  there  are  signs  that  the  Army’s  IT  acquisition  workforce  is  neither  large 
enough  nor  well  trained  enough  to  adequately  perfonn  its  oversight  role.  This  paper  will 
examine  this  issue,  and  offer  recommendations  on  how  to  improve  the  workforce’s 
effectiveness. 

The  Clinger-Cohen  Act  of  1996  defines  information  technology  as  follows: 

The  tenn  ‘infonnation  technology,’  with  respect  to  an  executive  agency,  means 
any  equipment  or  interconnected  system  or  subsystem  of  equipment,  that  is  used 
in  the  automatic  acquisition,  storage,  manipulation,  management,  movement, 
control,  display,  switching,  interchange,  transmission,  or  reception  of  data  or 
infonnation  by  the  executive  agency. 1 

This  is  a  very  broad  definition,  and  this  paper  will  restrict  it  slightly.  It  will 
exclude  pure  communication  technology  (satellites,  cell  phones,  etc.)  and  focus  on  the 
computer  systems  that  allow  for  the  storage,  sharing,  and  use  of  the  information  an 
organization  needs  to  perform  its  function. 

Background 

The  Push  to  Outsource 

Starting  with  the  development  of  the  revolutionary  Electronic  Numerical 
Integrator  And  Computer  (ENIAC)  in  the  late  1940s,  the  Anny  has  historically  taken  a 
very  active  role  in  developing  the  IT  it  needs.  Indeed,  as  late  as  the  early  1980s,  Army 
civilian  and  military  personnel  developed  most  of  the  software  used  by  the  Army’s 
information  systems.  But  a  variety  of  factors  conspired  to  push  this  development  work 
out  of  the  Anny  and  into  the  private  commercial  sector. 


The  Commercial  Sector  Takes  the  Lead  in  IT 


The  commercial  sector  quickly  realized  the  value  of  IT.  Businesses  invested 
heavily  in  it,  spurring  rapid  development  in  this  sector.  By  the  late  1980s,  a  large  amount 
IT  innovation  was  coming  from  outside  government — from  commercial  companies  like 
Sun,  Oracle,  and  Microsoft.  By  the  dawning  of  the  Internet  Age  in  the  1990s,  the 
commercial  IT  sector  dwarfed  the  government  sector.  The  Army,  along  with  the  rest  of 
the  Department  of  Defense  (DoD),  began  to  realize  that  it  could  leverage  this  commercial 
work  for  its  own  use.  After  all,  why  reinvent  the  wheel?  A  prime  example  of  this  was  the 
famous  “Perry  Memo”  written  by  then  Secretary  of  Defense  William  J.  Perry  in  1994, 
which  directed  the  DoD  to  use  commercial  standards  and  technology  whenever  possible 
before  looking  at  custom  military-specification  solutions.3  At  roughly  the  same  time,  the 
Federal  Acquisition  and  Streamlining  Act  directed  agencies  to  procure  commercially 
available  items  over  custom-developed  ones  to  the  maximum  extent  possible.4 

Don ’t  Compete  with  Private  Industry 

As  far  back  as  the  Eisenhower  Administration,  there  has  been  a  push  to  ensure 
that  the  government  is  not  competing  with  the  private  sector.  In  1955,  the  US  Bureau  of 
the  Budget  (forerunner  of  the  Office  of  Management  and  Budget)  issued  Bulletin  Number 
55-4,  which  stated:  “It  is  the  general  policy  of  the  administration  that  the  Federal 
Government  will  not  start  or  carry  on  any  commercial  activity  to  provide  a  service  or 
product  for  its  own  use  if  such  product  or  service  can  be  procured  from  private  enterprise 
through  ordinary  business  channels.”5 

In  1965,  the  first  major  piece  of  legislation  dealing  specifically  with  IT 
procurement  appeared.  The  Brooks  Act  of  1965  required  federal  agencies  to  procure  IT 
through  competition  and  lowest  price  bidding,  and  to  centrally  manage  this  process.6  This 
legislation  started  the  government  down  the  road  of  depending  on  the  commercial  sector 
for  IT  products  and  systems. 
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The  following  year,  the  Bureau  of  the  Budget  issued  Circular  A-76,  which 

provided  guidance  to  agencies  for  detennining  whether  to  develop  internally  or  simply 

buy  needed  goods  and  services.  This  publication  has  been  revised  numerous  times,  and  is 

still  in  force  today.  The  current  version  (2003)  states: 

The  longstanding  policy  of  the  federal  government  has  been  to  rely  on  the  private 
sector  for  needed  commercial  services.  To  ensure  that  the  American  people 
receive  maximum  value  for  their  tax  dollars,  commercial  activities  should  be 
subject  to  the  forces  of  competition.7 

Under  the  Clinton  Administration,  the  National  Performance  Review  (NPR)  was 
created  and  led  by  Vice  President  A1  Gore  to  make  government  more  efficient  and 
responsive  to  its  customers.  According  to  the  NPR  charter,  one  way  a  government  agency 

o 

should  accomplish  this  is  by  “cutting  back  to  basic  missions.”  Through  its  reporting 
requirements  and  award  programs,  the  NPR  process  brought  pressure  on  agencies  to 
outsource  “non-core”  activities. 

In  1999,  the  pressure  continued  to  mount  when  the  Federal  Activities  Inventory 
Refonn  Act  (FAIR)  defined  what  functions  were  considered  “inherently  governmental” 
(i.e.,  could  not  be  contracted  out)  and  required  agencies  to  list  which  of  their  functions 
could  be  performed  by  private  industry.9  Circular  A-76  was  revised  to  include  this 
requirement,  and  the  push  to  outsource  began  in  earnest. 

The  current  Circular  A-76  defines  an  inherently  governmental  activity  as  “. . . .an 
activity  that  is  so  intimately  related  to  the  public  interest  as  to  mandate  performance  by 
government  personnel.”  It  defines  only  two  categories  of  this  activity: 

•  the  exercise  of  sovereign  government  authority  or  the  establishment  of 

procedures,  and 

•  processes  related  to  the  oversight  of  monetary  transactions  or  entitlements. 10 

However,  the  Circular  goes  on  to  state  that  not  everything  to  do  with  these 

categories  is  automatically  inherently  governmental,  for  example: 

An  activity  may  be  provided  by  contract  support  (i.e.,  a  private  sector  source  or  a 
public  reimbursable  source  using  contract  support)  where  the  contractor  does  not 
have  the  authority  to  decide  on  the  course  of  action,  but  is  tasked  to  develop 
options  or  implement  a  course  of  action,  with  agency  oversight. 1 1 
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This  very  narrow  interpretation  of  inherently  governmental  leads  to  a  very  wide 
definition  of  what  could  (and  should)  be  turned  over  to  the  private  sector.  Basically,  if  an 
activity  doesn’t  involve  paying  out  money  or  exercising  government  authority,  it 
becomes  fair  game  for  outsourcing. 

A-76  pushes  outsourcing  even  further  by  requiring  agencies  to  provide  yearly 
inventories  of  inherently  governmental  and  commercial  activities  perfonned  by 
government  personnel  and  establishing  a  process  by  which  anyone  may  challenge  which 
list  an  activity  should  be  on.  It  also  requires  agencies  to  perform  competitions  between 
government  employees  and  commercial  business  before  allowing  any  new  commercial 
activity  or  expansion  of  an  existing  commercial  activity  to  be  perfonned  by  government 
employees.  The  message  is  clear — unless  it  is  truly  core  government  business  or  you  can 
prove  the  government  can  do  it  cheaper,  you  need  to  outsource. 

The  Shrinking  Military 

Since  the  end  of  the  Cold  War  with  the  fall  of  the  Berlin  Wall  in  1989,  there  has 
been  a  steady  push  to  downsize  military  manpower  as  a  way  of  saving  money-cashing  in 
on  the  so-called  “Peace  Dividend.”  In  1989,  the  Anny  stood  at  over  760,000  active 
military  and  over  380,000  civilians.  Today,  in  the  middle  of  the  Global  War  on 
Terrorism,  the  Army’s  strength  is  only  460,000  active  soldiers  and  260,000  civilians.  The 
other  anned  services  have  taken  similar  cuts.  12  This  lack  of  manpower  puts  great 
pressure  on  the  services  to  outsource  anything  considered  non-warfighting.  Acquisition, 
including  IT  acquisition,  falls  into  this  non-warfighting  category,  and  has  taken  sizeable 
manpower  cuts.  For  example,  the  DoD  as  a  whole  underwent  a  29%  reduction  in  the 
acquisition  workforce  from  1991  to  2001. 

IT  Outsourcing  Goes  Mainstream 

While  the  DoD  was  wrestling  with  these  budgetary  and  manpower  issues,  so  was 
private  industry.  In  the  90s,  companies  began  looking  at  outsourcing  many  functions  not 
considered  core  to  their  business.  This,  they  believed  would  help  them  focus  on  what  they 
did  best,  while  allowing  other  companies  with  more  expertise  to  handle  support  functions 
(such  as  human  resources,  accounting,  plant  maintenance,  etc.).  One  of  the  early 
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proponents  of  this  approach,  Eastman  Kodak  outsourced  all  their  IT  to  an  outside 
company  in  1990.  They  were  quickly  followed  by  dozens  of  major  companies  who 
decided  that,  while  they  needed  the  infonnation  that  IT  systems  provided,  they  didn’t 
need  to  actually  build  or  operation  the  IT  systems  in  order  to  get  that  information.  14 

The  Result — Army  IT  Outsourcing 

With  all  these  forces  at  work — an  ever  more  competent  and  innovative 
commercial  IT  sector,  a  push  to  outsource  non-core  government  functions,  a  lack  of 
available  Army  manpower  to  do  the  job,  and  a  belief  in  the  value  of  IT  outsourcing  as  a 
viable  business  practice — the  Army,  along  with  the  rest  of  the  DoD  and  the  Federal 
government,  slowly  divested  itself  of  its  ability  to  build  its  own  IT. 

Today,  government  IT  outsourcing  is  big  business.  The  General  Accounting 
Office  (GAO)  reported  that  in  FY  2001,  the  DoD  obligated  more  than  $6.2  billion  to 
outsourced  IT  services. 15  A  recent  market  survey  concluded  that  the  US  government's 
outsourcing  of  infonnation  technology  work  will  increase  nearly  6%  annually  through 
2011. 16 

Outsourcing  May  Have  Gone  Too  Far 

Over  the  last  ten  years,  there  have  been  signs  that  the  government  may  have 
outsourced  too  much.  Some  have  raised  the  alarm  that  the  government  may  no  longer 
have  the  expertise  to  effectively  oversee  the  work  its  contractors  are  doing. 

Talk  in  the  Press 

Recently,  there  has  been  much  criticism  in  the  press  of  contractors  gaining  too 
much  sway  over  the  government.  Industry  and  government  observers  are  beginning  to 
question  whether,  after  years  of  downsizing  and  outsourcing,  government  agencies  have 
enough  skilled  personnel  left  to  oversee  what  the  contractors  are  doing.  As  one 
contracting  attorney  put  it,  “Contracting  has  certainly  grown,  but  the  mechanism  to 
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monitor  and  evaluate  what  the  contractors  are  doing  hasn’t  grown.” 

This  sort  of  criticism  isn’t  limited  to  the  government  sector.  There  is  starting  to  be 
some  pushback  to  private  outsourcing  as  well,  and  articles  about  insourcing — bringing  IT 
work  back  in-house — are  beginning  to  appear.  A  2007  study  by  CIO  Insight  Magazine 
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determined  that  most  IT  executives  feel  outsourcing  is  overrated  as  a  cost  saver  and  that 
managing  outsourced  efforts  requires  more  effort  than  originally  believed.  In  fact,  an 
average  of  20%  of  their  previously  outsourced  IT  applications  and  services  had  been 
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insourced  within  the  last  12  months.  As  one  major  corporate  chief  infonnation  officer 
(CIO)  told  CIO  Magazine,  “. . . .  no  one  will  understand  your  strategic  needs  better  than 
the  people  whose  livelihood  depends  on  the  success  of  the  company." 19 

Few  are  claiming  that  outsourcing  is  dying,  but  many  argue  that  more  emphasis 
must  to  be  placed  on  dealing  with  the  difficulties  of  managing  outsourced  efforts. 

Evidence  within  the  Government 

In  a  2001  report  on  the  future  of  the  Government  IT  workforce,  the  GAO  noted 
that  there  was  no  strategic  plan  to  ensure  adequate  talent  to  oversee  IT  procurement  and 

operations,  and  that  “. .  .agencies  appear  to  be  at  risk  of  not  having  enough  of  the  right 
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people  with  the  right  skills  to  manage  service  procurements.”' 

In  2008,  David  M.  Walker,  Comptroller  General  of  the  United  States  testified 

before  the  House  of  Representatives  Anned  Services  Committee  on  this  problem,  stating, 

“Unless  the  federal  government  pays  the  needed  attention  to  the  types  of  functions  and 

activities  perfonned  by  contractors,  agencies  run  the  risk  of  losing  accountability  and 

control  over  mission-related  decisions.”  He  cited  the  wide  use  of  government  contractors 

providing  professional  and  management  support  services,  which  he  deemed  risky  because 

these  personnel,  who  support  government  decision  makers,  can  easily  influence 

inherently  governmental  decision  making.  In  his  words,  it  is  critical  to,  “ensure  that 

government  decisions  reflect  the  independent  judgment  of  agency  officials  and  that 

agency  officials  retain  control  over  and  remain  accountable  for  policy  decisions  that  may 
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be  based  on  contractor  work  products.”' 

In  2006,  the  Director  of  National  Intelligence  reported  that  the  intelligence 
community  is  competing  with  its  contractors  for  employees  and  has  no  choice  but  to  use 
contractors  for  work  that  is  “borderline  inherently  governmental.”  Whether  or  not  the 
work  should  be  done  in-house  had  become  a  moot  question.  There  weren’t  enough  skilled 
government  personnel  left  to  do  the  work,  and  the  salaries  offered  by  the  contractors 
made  it  difficult  to  hire  skilled  personnel  into  government  service. 
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Various  members  of  Congress  have  weighed  in  on  the  issues  of  outsourcing, 
government  oversight,  and  inherently  governmental  functions.  The  House  Armed 
Services  Committee’s  Readiness  Subcommittee  held  hearings  on  inherently 
governmental  work  in  March  of  2008.  The  chairmen,  Representative  Solomon  Ortiz  (D- 
TX),  stated,  “With  [DoD]  and  the  military  facing  new  challenges  and  responsibilities, 
Congress  should  redefine  what  is  considered  inherently  governmental.”  “  Representative 
Tom  Davis  (R-VA)  of  the  Oversight  and  Government  Report  Committee  said  reforms  are 
needed  to  keep  a  closer  eye  on  contractors,  and  he  stressed  the  need  for  a  larger  and  better 
trained  government  acquisition  workforce.  Representative  Henry  Waxman  (D-CA),  the 
committee  chair,  also  went  on  record  describing  egregious  contract  abuses  and  the  need 
for  increased  oversight.'  Shay  Assad,  Director  of  Procurement  and  Acquisition  Policy  at 
the  DoD,  stated,  “I  do  think  the  time  has  come  when  we  step  back  and  take  another 

24 

look — a  hard  look — at  how  we’re  defining  'inherently  governmental.  ” 

Besides  the  dangers  of  putting  too  much  control  in  the  contractor’s  hands,  there  is 
also  the  issue  that,  while  a  contractor  may  do  exactly  what  the  contract  states,  it  doesn’t 
guarantee  that  the  military  users  of  the  product  will  be  satisfied  with  the  results.  The 
contractor  is  bound  only  by  the  contract,  not  by  whether  or  not  his  work  actually  adds 
value.  And  if  the  contract  isn’t  perfectly  worded,  things  can  go  awry.  For  example,  the 
Army’s  Total  Army  Communications — Southwest  Asia  (TACSWA)  was  criticized  by  the 
GAO  because  customer  satisfaction  wasn’t  even  mentioned  in  the  contract.  '  More 
recently,  the  Navy  Marine  Corps  Intranet  Program  met  with  the  similar  criticism.  While 
the  Navy  had  developed  a  large  set  of  perfonnance  goals  for  the  program,  those  goals 
weren’t  actually  written  in  the  contract.  Upon  review,  the  contractor  was  only  meeting 
15%  of  those  goals.  Both  cases  illustrate  major  weaknesses  in  outsourcing  complicated 
work  such  as  IT  system  development.  The  contract  requirements  don’t  always  fully 
capture  everything  the  government  wants  done,  and  government  program  managers 
aren’t  always  actively  managing  the  program,  adjusting  the  contract  if  necessary,  to  make 
sure  that  the  end  product  really  meets  the  user’s  needs.  Merely  having  a  contract  and 
more  or  less  passively  watching  someone  execute  it  is  not  a  recipe  for  success. 
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Growing  Concerns  about  IT  Security 

Besides  raising  concerns  about  program  performance,  outsourcing  IT  has  also 
been  criticized  for  adding  infonnation  security  risks.  In  a  2007  study,  the  Defense 
Science  Board  stated  that,  “DoD  has  become  increasingly  dependent  for  mission-critical 
functionality  upon  highly  interconnected,  globally  sourced,  infonnation  technology  of 
dramatically  varying  quality,  reliability  and  trustworthiness.”  They  went  on  to  note  that  in 
today’s  world,  many  DoD  systems  contain  software  that  was  developed  in  foreign 
countries  whose  interests  do  not  coincide  with  ours,  and  that  this  presented  the 
opportunity  for  them  to  exploit  this  software  by  inserting  malicious  code  allowing  them 
to  gain  access  to  or  deny  the  US  use  of  its  IT  systems.27  The  GAO  had  similar  concerns, 
noting  in  2004  that  many  DoD  program  managers  have  trusted  their  contractors  to  ensure 
that  the  software  was  secure,  yet  the  contractors  were  “only  focused  on  quality  and 
functionality,  not  security.  No  one  was  actually  checking.”  It  is  conceivable  that  no  one 
in  the  program  offices  was  checking  because  they  lacked  the  skilled  personnel  to  do  so. 

Congress  Starts  to  Act 

As  Congress  has  become  increasingly  aware  of  some  of  the  problems  associated 
with  outsourcing,  it  has  begun  to  take  action.  As  part  of  the  2008  Defense  Authorization 
Act,  Congress  specifically  banned  the  further  use  of  lead  systems  integrators  on  new 
programs."  A  lead  systems  integrator  is  a  contractor  hired  by  the  government  not  to 
build  the  new  product,  but  to  coordinate  and  manage  other  contractors.  The  Army  used 
this  approach  for  the  Future  Combat  System  (FCS),  and  the  Coast  Guard  used  it  for  their 
Deepwater  fleet  modernization  program.  Pentagon  officials  as  high  as  the  Office  of  the 
Secretary  of  Defense  (OSD)  Director  of  Procurement  Policy,  as  well  as  various  GAO 
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officials,  have  suggested  that  lead  systems  integrators  may  be  infringing  on  inherently 
governmental  functions — giving  the  contractor  too  much  control  and  leaving  the 
government  not  fully  in  charge  of  the  program.  While  the  Army  is  continuing  the  use  of 
the  lead  system  integrator  on  the  FCS  (with  congressional  approval),  the  Coast  Guard  has 
decided  to  bring  that  function  back  into  government  hands.  Coast  Guard  Commandant 
Admiral  Thad  Allen  commented,  “We’ve  relied  too  much  on  contractors  to  do  the  work 
of  government  as  a  result  of  tightening  budgets,  a  dearth  of  contracting  expertise  in  the 
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federal  government,  and  a  loss  of  focus  on  critical  governmental  roles  and  responsibilities 

32 

in  the  management  and  oversight  of  acquisition  programs.” 

Reining  in  lead  system  integrators  was  only  the  beginning.  The  2008  Defense 
Authorization  Act  also  took  the  teeth  out  of  OMB  Circular  A-76  for  the  DoD.  The  Act 
prohibited  OMB,  or  anyone  else,  from  forcing  the  DoD  to  perform  any  more  A-76 
competitions  to  outsource  work.  It  changed  the  rules  of  the  A-76  commercial-vs- 
government  competition  process  to  be  more  favorable  to  government  workers34  It  also 
directed  the  DoD  to  give  special  consideration  for  using  government  workers  over 
contractors  for  new  functions  and  for  insourcing  functions  currently  outsourced, 
especially  functions  “closely  associated  with  the  performance  of  an  inherently 
governmental  function.” 

The  Act  went  on  to  require  the  OSD  to  create  a  Defense  acquisition  workforce 
Strategic  Human  Capital  Plan  and  establish  an  Acquisition  Workforce  Development  Fund 
to  ensure  that  the  DoD  can  recruit,  train  and  maintain  the  force  it  needs  to  provide 
adequate  contractor  oversight.  It  also  extended  the  Secretary’s  authority  to  fill  shortage 
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acquisition  positions,  providing  the  tools  to  grow  the  acquisition  workforce. 

Less  than  a  year  later,  Congress  took  even  more  outsourcing-related  action  with 
the  2009  Defense  Authorization  Act.  This  time  Congress  took  aim  at  personal  sendee 
contracts.  These  are  contracts  that  can  be  used  to  hire  contractors  to  work  in  DoD  offices 
side-by-side  with  government  workers,  assisting  them  in  the  execution  of  their  staff 
duties.  Clearly  concerned  with  how  much  influence  these  contractors  might  be  having 
over  government  decisions,  Congress  required  the  Secretary  of  Defense  to: 

“ . develop  guidance  related  to  personal  services  contracts  to: 

(1)  require  a  clear  distinction  between  employees  of  the  DoD  and  employees  of 
DoD  contractors 

(2)  provide  appropriate  safeguards  with  respect  to  when,  where,  and  to  what 
extent  the  Secretary  may  enter  into  a  contract  for  the  procurement  of  personal 
services;  and 

(3)  assess  and  take  steps  to  mitigate  the  risk  that,  as  implemented  and 
administered,  non-personal  services  contracts  may  become  personal  services 
contracts.”37 
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The  Act  further  directs  the  Administrator  of  Federal  Procurement  Policy  to: 

. .  .develop  and  issue  a  standard  policy  to  prevent  personal  conflicts  of  interest  by 
contractor  employees  perfonning  acquisition  functions  closely  associated  with 
inherently  governmental  functions  (including  the  development,  award,  and 
administration  of  Government  contracts)  for  or  on  behalf  of  a  Federal  agency  or 

38 

department. 

Analyzing  the  congressional  actions,  it  is  easy  to  detennine  the  intent  of  Congress.  They 
are  concerned  that  DoD  has  outsourced  too  much,  and  needs  to  more  forcefully  protect 
and  perfonn  its  inherently  governmental  responsibilities. 

The  Result 

With  all  these  opinions  from  press  and  the  GAO,  and  the  current  mood  (and 
forceful  actions)  of  Congress,  it  appears  that  the  Army  is  entering  a  new  era  with  regard 
to  outsourcing  in  general  and  IT  outsourcing  in  particular.  While  the  Army  certainly  isn’t 
returning  to  the  “do  it  yourself’  mentality  of  forty  years  ago,  the  importance  of  truly 
effective  oversight — having  the  talent  and  experience  to  tell  the  contractors  exactly  what 
the  Army  needs,  and  then  managing  them  to  make  sure  the  Army  gets  it — is  on  the  rise. 

The  Need  for  the  Army  IT  Acquisition  Professional 

To  provide  this  oversight  and  to  manage  the  IT  development  efforts,  the  Army 
simply  must  have  sufficiently  trained  and  experienced  government  IT  acquisition 
specialists,  personnel  who  truly  understand  and  appreciate  the  unique  complexities  of  IT 
and  can  guide  the  contractors  and  the  development  process. 

A  2002  study  on  outsourcing  by  the  Gartner  Group  stressed  the  importance  of 
good  contract  oversight:  “Without  a  well-designed  and  well-implemented  strategy  for 
managing  the  deal  and  monitoring  performance,  the  good  intentions  for  outsourcing  will 
be  thwarted  by  poorly  designed,  poorly  funded  and  poorly  delivered  processes  for 
managing  the  delivery  of  services.”  The  lack  of  in-house  expertise,  both  in  the  business 
and  technical  realms,  greatly  increases  the  chance  of  program  failure. 

There  is  a  prevailing  view  that  all  one  needs  for  good  government  acquisition  are 
competent  contracting  officers,  skilled  in  writing  and  negotiating  contracts,  and  perhaps 
some  generic  program  managers,  skilled  in  managing  schedules  and  budgets.  In  this 
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view,  all  acquisition  programs  are  by  and  large  the  same,  and  require  the  same  skills  sets 
from  Army  personnel.  However,  in  reality  IT  programs  have  some  very  unique  qualities 
that  demand  a  specialized  government  IT  acquisition  workforce  to  manage  them. 

The  Unique  IT  Development  Cycle 

The  nonnal  process  the  US  military  uses  to  develop  any  new  system,  be  it  a  truck, 
airplane,  or  computer  system  is  spelled  out  in  DoD  Instruction  5000.2.  As  described 
there,  the  new  system  goes  through  a  rather  formal  lock-step  process,  progressing  from 
concept  to  demonstration,  and  then  on  to  production,  deployment,  and  support.40  Once  in 
the  field,  any  upgrade  is  treated  in  the  exactly  same  way — each  upgrade  is  packaged  as  an 
increment,  and  progresses  through  the  same  stages.  At  each  step  along  the  way  are  a 
series  of  fonnal  milestone  decision  points J  requiring  a  program  manager  to  gain  fonnal 
approval  from  his  milestone  decision  authority  before  progressing. 

Officially,  IT  systems  are  supposed  to  follow  this  same  development  process,  but 
the  reality  is  often  very  different.  After  all,  the  key  component  of  an  information  system 
isn’t  metal  or  brick,  but  software,  which  is  much  easier  to  change. 

For  example,  to  upgrade  a  weapons  system  or  vehicle,  one  normally  has  to  return 
that  item  to  a  depot  or  send  an  upgrade  team  to  visit  every  place  in  the  Army  where  the 
equipment  exists.  This  makes  any  improvement  a  huge,  costly  endeavor,  requiring 
extensive  fonnal  processes  to  ensure  everything  works  as  planned.  As  a  result,  one 
doesn’t  make  changes  frequently.  Instead,  many  changes  are  bundled  into  a  single 
upgrade  effort  that  will  take  years  to  complete.  The  bundled  upgrade  becomes 
complicated  and  very  expensive.  It’s  very  important  to  get  it  right  the  first  time — few 
program  managers  can  afford  a  second  upgrade  package  to  fix  the  first  one.  As  a  result,  it 
makes  sense  to  put  the  upgrade  through  all  the  steps  of  the  DoD  acquisition  process  like 
any  new  system  in  order  to  avoid  any  costly  mistakes. 

Upgrading  an  IT  system  can  be  much  simpler  than  a  non-IT  system.  It  can  be  as 
simple  as  loading  new  software  on  a  single  set  of  servers  in  some  central  location,  or 
mailing  a  set  of  software  compact  disks  to  users  around  the  world  for  them  to  install.  If 
the  hardware  (i.e.,  servers  and  network  equipment)  needs  replacing,  it  is  often  located  in  a 
very  small  number  of  locations,  perhaps  just  one  primary  server  room  and  one  backup 
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facility.  No  need  for  a  factory  assembly  line  or  vast  numbers  of  fielding  teams — one  just 
makes  the  changes  and  moves  on. 

Because  of  how  quickly  changes  and  improvements  can  be  made,  IT  system 
product  managers  can  adopt  a  different,  more  fluid  model.  Instead  of  bundling  up  a  large 
number  of  changes  into  a  multi-year  software  development  effort,  one  can  make  small 
changes  throughout  the  year  under  the  heading  of  software  maintenance.  Small  mistakes 
are  not  as  costly  to  correct  later — if  the  software  isn’t  exactly  perfect,  changes  can  be 
made  very  rapidly  as  opposed  to  waiting  years  for  the  next  upgrade.  This  allows  for  an 
abbreviated  development  process,  skipping  or  shortening  some  of  the  normal  steps 
because  there  is  less  need  to  be  “perfect”  on  day  one.  This  approach  sits  well  with  the  end 
users,  who  get  the  features  they  want  much  sooner  than  they  would  under  a  more  fonnal 
system. 

This  also  means  that  most  information  systems  are  constantly  in  all  phases  of 
development  simultaneously:  supporting  the  existing  version,  testing  the  next  update,  and 
starting  work  on  the  one  after  that.  It  is  a  very  different  battle  rhythm  from  non¬ 
information  (i.e.,  tanks,  trucks,  etc.)  system  development,  requiring  a  different  mindset 
for  the  program  management  team.  In  the  words  of  Mr.  Gary  Winkler,  Army  Program 
Executive  Officer  for  Enterprise  Infonnation  Systems,  "In  a  typical  three  year  tour,  a 
weapons  system  product  manager  might  take  his  system  from  one  DoD  milestone  to 
the  next.  In  that  same  time,  an  effective  IT  product  manager  will  take 
his  system  through  all  the  milestones.”41 

Unique  IT  System  Rules  and  Authorities 

In  1996,  the  Clinger-Cohen  Act  made  it  very  clear  that  IT,  and  specifically 
information  systems,  had  to  be  treated  differently  from  other  types  of  development  and 
procurement.42  It  also  formally  established  the  position  of  the  DoD  CIO,  with  significant 
authority  over  the  development  of  new  IT  systems.  Since  the  enactment  of  Clinger- 
Cohen,  developers  of  infonnation  systems  have  had  to  answer  to  the  DoD  and  Service 
CIO’s,  something  other  program  managers  don’t  have  to  do.  This  was  done  both  to 
recognize  the  unique  nature  of  the  development  of  infonnation  systems  and  to  urge 
infonnation  system  developers  to  work  towards  increased  data  interoperability.  The  Act 
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added  many  special  hoops  through  which  IT  programs  had  to  jump,  from  infonnation 
assurance  to  economic  analysis  to  information  architecture  compliance.  These 
requirements,  coupled  with  directives  from  the  DoD  CIO,  have  created  many  unique 
requirements  that  only  IT  programs  need  to  comply  with.  In  fact,  the  single  largest 
chapter  in  the  DoD  Acquisition  Guidebook,  the  “Bible”  for  DoD  program  managers,  is 
the  chapter  on  unique  IT  system  acquisition  requirements.43 

Navigating  this  maze  of  additional  requirements  and  organizations  is  a 
challenge — not  for  the  uninitiated  or  faint-hearted.  Personnel  with  extensive  experience 
working  with  IT  systems  under  these  rules  would  make  the  task  much  easier. 

Unique  IT  System  Security  Requirements 

Information  Assurance — protecting  systems  from  outside  attacks  and 
disruptions — has  become  a  specialized  field  of  knowledge  all  its  own.  Regardless  of  the 
purpose  of  any  given  IT  system,  if  it  connects  to  a  network  then  it  must  be  protected.  This 
protection  needs  to  be  considered  in  all  phases  of  system  development.  Protection  cannot 
simply  be  “bolted  on”  at  the  end  of  development.  As  mentioned  earlier,  both  DoD  and  the 
Anny  have  laid  significant  reporting,  compliance,  and  testing  requirements  on  IT 
systems,  from  the  DoD  Information  Assurance  Certification  and  Accreditation  Process 
(DIACAP)44  to  the  Anny’s  Certificate  of  Networthiness  Program.45 

If  a  development  contractor  makes  a  mistake  in  this  critical  arena,  it  could  be 
extremely  costly.  At  best,  this  will  result  in  schedule  delays  and  cost  overruns  as  the 
system  is  reworked  in  order  to  meet  DoD  and  Army  requirements.  At  worst,  the  system 
will  be  fielded  with  significant  vulnerabilities  that  an  enemy  can  exploit.  The  Anny  will 
pay  a  high  price  if  an  enemy  compromises  the  system  and  steals  or  corrupts  its  data. 

Developing  IT  systems  requires  a  keen  understanding  of  the  dangers  and  threats 
in  cyberspace  in  the  same  way  that  developing  an  airplane  requires  an  understanding  of 
the  dangers  and  threats  in  the  atmosphere.  Army  personnel  overseeing  IT  system 
development  need  this  kind  of  in-depth  knowledge  to  ensure  contractors  don’t  make 
costly  emors. 
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Information  Technology  Development  Requires  Truly  Global  Thinking 

IT  systems  are  built  to  streamline  work  processes  and  provide  better  information 
and  ways  for  leaders  to  make  decisions.  Typically,  the  processes  being  improved  are 
extremely  complicated,  cross  over  many  different  organizations  and  communities,  and 
are  not  fully  documented  by  any  one  of  them.  A  simple  process  like  ordering  a  spare  part, 
processing  a  soldier’s  promotion,  or  plotting  enemy  positions  on  a  map  may  consist  of 
countless  steps  performed  by  many  people,  each  one  acting  on  a  combination  of  official 
written  procedures,  local  rules,  and  techniques  passed  on  from  previous  soldiers.  And  yet 
to  successfully  automate  this  process,  one  must  fully  understand  all  the  pieces. 

Additionally,  the  information  generated  by  a  system  might  be  needed  by 
personnel  in  many  different  organizations.  A  part  requisition,  for  example,  is  of  interest 
to  the  logistics  units  that  must  deliver  the  part,  the  lifecycle  manager  who  will  buy  the 
part,  the  finance  organization  that  will  pay  for  the  part,  the  operational  commander  who 
wants  to  know  when  the  part  will  arrive  so  his  vehicle  can  be  fixed,  etc.  All  these 
customers  have  become  stakeholders  with  a  vested  interest  in  the  information  within  the 
system.  This  group  of  stakeholders  can  be  much  more  diverse  than  say,  those  with  a  stake 
in  a  new  rifle  or  vehicle  program. 

For  example,  when  preparing  for  the  replacement  of  the  Army’s  Electronic 
Military  Personnel  Office  (eMILPO)  with  the  Defense  Integrated  Military  Human 
Resource  System  (DIMHRS),  it  was  discovered  that  many  different  organizations,  from 
the  8th  Army  in  Korea  to  the  Anny’s  Central  Issuing  Facilities,  were  taking  personnel 
information  from  eMILPO  and  using  it  in  their  own  infonnation  systems.  Many  of  these 
customers  were  not  “personnel”  organizations  at  all — they  included  logistics,  finance, 
training,  and  installation  support  organizations.  To  transition  to  DIMHRS,  one  couldn’t 
just  work  with  representatives  of  the  personnel  community — virtually  everyone  in  the 
Anny  was  a  “customer”  of  the  systems. 

Because  of  this  kind  of  complexity,  information  system  developers  can  seldom 
just  work  from  a  written  requirements  document,  or  with  a  single  functional  proponent. 
They  have  to  be  expert  at  working  hand-in-hand  with  a  large  number  of  stakeholders  to 
ensure  that  the  new  system  meets  the  needs  of  all  users. 
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Occasionally,  the  Army  does  acknowledge  the  uniqueness  of  IT  development.  For 
example,  at  the  2008  US  Army  Acquisition  Awards  Ceremony,  besides  the  normal 
awards  for  best  project/product  manager,  there  was  a  separate  category  for  excellence  in 
“Information  Enabled  Army.”  This  recognized  the  fact  that  IT  system  development  is 
separate  and  distinct  from  traditional  program  management.46 

The  Role  of  the  Army  IT  Acquisition  Professional 

As  suggested  throughout  this  paper,  oversight  is  more  than  just  passively 
watching  the  contractor  do  the  work.  An  Army  program  manager  and  his  staff  must 
actively  guide  the  contractor  to  produce  what  the  Anny  needs.  He  has  to  anticipate 
problems  before  they  affect  cost,  performance,  or  schedule,  and  work  with  the  contractor 
and  other  agencies  to  solve  those  problems.  If  he  does  not,  the  system  he  is  responsible 
for  developing  is  likely  to  take  longer,  cost  more,  and  do  less  than  the  Anny  expects. 

Because  of  the  unique  nature  of  infonnation  systems  acquisition,  the  right  person 
with  the  right  skills  and  experience  can  pay  big  dividends  in  program  management. 
Whether  in  a  program  leadership  or  supporting  staff  role,  the  IT  acquisition  professional 
can  help  a  development  effort  succeed  in  all  phases  of  the  program. 

While  there  is  no  official  list  of  duties  for  IT  acquisition  professionals  published 
by  OSD  or  the  Anny,  the  following  are  a  few  of  the  areas  where  a  well-trained  and 
experienced  Army  IT  Acquisition  Professional  can  add  tremendous  value: 

Preparing  Requests  for  Proposal  (RFPs).  The  contracting  officer  needs  assistance 
in  the  preparation  of  the  documents  telling  contractors  what  the  Army  wants  built.  While 
functional  requirements  (what  the  system  must  do  for  the  end  user)  are  a  large  part  of 
this,  so  are  technical  constraints,  such  as  required  software  that  must  be  used  (or  cannot 
be  used),  interoperability  issues,  and  IT  compliance  constraints  (Joint  Interoperability 
Test  Center  testing,  NETCOM  Certificates  of  Networthiness,  DIACAP  standards,  etc.) 
that  the  system  will  have  to  comply  with  in  order  to  be  fieldable.  IT  acquisition  personnel 
can  synthesize  the  user  requirements  with  any  technical  requirements  to  ensure  the  final 
system  will  meet  everyone’s  needs. 

Evaluating  Contractor  Proposals.  While  it  might  seem  acceptable  at  first  thought 
for  the  Anny  program  office  to  simply  ensure  the  proposal  meets  the  standards  in  the 
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RFP  and  then  just  pick  the  lowest  bidder,  this  approach  is  seldom  sufficient.  Each 
contractor  may  propose  very  different  approaches,  architectures,  and  technical  solutions. 
While  all  will  claim  that  their  proposed  approach  is  guaranteed  to  succeed,  a  long  line  of 
failed,  late,  and  over-budget  programs  shows  this  is  not  always  the  case. 

IT  acquisition  personnel  must  be  able  to  evaluate  the  proposals  to  ensure  that  the 
costs  and  schedule  proposed  are  reasonable.  They  must  use  their  technical  expertise  and 
history  of  working  on  similar  programs  to  help  detennine  if  each  proposal  is  actually 
likely  to  succeed.  This  avoids  intentional  or  unintentional  low  bids — where  the  contractor 
is  unreasonably  optimistic  on  how  long  it  will  take  or  how  much  it  will  cost.  Without  this 
external  “sanity  check,”  the  Anny  could  pick  a  contractor  who,  in  the  end,  cannot  deliver 
without  additional  cash  or  time  that  the  Army  cannot  afford. 

Additionally,  contractors  often  propose  novel  solutions  that  may  add  benefits  not 
specified  in  the  RFP.  If  the  proposal  is  being  evaluated  for  best  value — very  common  in 
DoD  these  days — rather  than  simply  lowest  price,  then  the  IT  acquisition  personnel  must 
be  able  to  evaluate  how  much  added  value  each  proposal  contains. 

Developing  Schedule  and  Budget.  As  with  all  programs,  there  is  more  to  the 
budget  and  schedule  than  just  the  contractor’s  work.  The  schedule  and  budget  have  to 
include  testing  by  various  oversight  agencies  (Joint  Interoperability  Test  Center,  Army 
Test  and  Evaluation  Command,  the  user  community,  etc.);  creation  of  documents  that 
have  to  be  submitted  to  outside  agencies  for  review  (NETCOM  Certificate  of 
Networthiness,  DIACAP  Authority  to  Operate,  Army  and  DoD  IT  Registration  databases, 
etc.);  and  various  user  training  and  fielding  activities.  Because  of  a  career  spent  taking  IT 
systems  through  these  hurdles,  the  IT  acquisition  professional  can  better  estimate  how 
long  the  process  will  actually  take,  and  what  it  will  cost  the  Anny. 

Monitoring  Schedule  and  Budget.  IT  acquisition  professionals  must  be  able  to 
keep  track  of  where  the  system  is  in  its  development,  and  whether  the  time  and  money 
remaining  will  be  adequate  to  complete  the  job.  This  requires  more  than  just  checking  off 
days  on  a  calendar.  The  IT  program  office  staff  needs  to  analyze  each  new  problem  or 
stumbling  block  that  arises,  and  validate  the  contractor’s  estimates  on  how  long  (and  how 
much)  it  will  take  to  get  the  program  back  on  track.  It  is  not  enough  to  simply  know 
where  one  is  in  the  program;  Anny  leaders  constantly  want  to  know  how  much  longer  it 
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is  really  going  to  take.  To  do  this  kind  of  projecting  and  validating  requires  technical 
knowledge  and  a  history  of  working  with  similar  IT  system  development  efforts. 

Suggesting  and  Evaluating  Performance/Schedule/Budget  Tradeoffs.  As  with  all 
programs,  things  go  wrong.  When  this  occurs,  a  contractor  may  offer  to  lower  a 
perfonnance  requirement  to  shorten  the  schedule  or  decrease  the  budget.  Examples  of 
this  would  be  eliminating  a  feature  of  the  systems  in  order  to  meet  a  key  test  date  or 
changing  to  lower  costing  hardware  in  order  to  save  money.  Much  like  evaluating  initial 
proposals,  the  Anny  needs  to  feel  comfortable  that  the  new  adjusted  schedule  and  budget 
are  realistic  and  likely  to  still  result  in  a  worthwhile  system.  The  IT  acquisition 
professional  should  be  a  key  player  in  evaluating  the  potential  changes. 

Identifying  and  Analyzing  Risk.  The  experienced  IT  acquisition  professional  is  in 
the  best  position  to  define  risks  to  the  program,  be  they  technical  or  regulatory.  The  IT 
acquisition  professional  will  know  from  past  experience  what  particular  “bumps  in  the 
road”  are  likely  to  occur.  Done  correctly  by  people  with  the  right  skills  and  experience, 
good  risk  definition  and  analysis  will  increase  the  accuracy  of  program  schedules  and 
budgets,  helping  the  program  manager  determine  where  within  the  program  to  focus  the 
team’s  effort  in  order  to  keep  things  on  track. 

Evaluating  Interim  Deliverables.  As  a  system  is  developed,  various  documents 
are  delivered:  things  such  as  data  dictionaries,  interface  specifications,  design  documents, 
etc.  Each  of  these  deliverables  has  to  be  accepted  by  the  government.  Acceptance  means 
that  the  document  is  correct  and  can  be  used  to  guide  the  next  step  of  the  project. 
Someone  must  review  and  evaluate  each  document — someone  with  the  technical 
knowledge  to  understand  it,  and  the  user  knowledge  to  be  able  to  assess  the  impact  on  the 
Anny  customer(s).  The  experienced  IT  acquisition  professional  is  perfectly  situated  to 
perfonn  this  critical  role. 

Evaluating  Contractor  Performance.  Many  IT  development  contracts  involve 
award  fees — bonus  money  that  the  contractor  can  earn  over  the  course  of  the  program.  It 
can  be  difficult  to  make  these  awards  appropriately.  Most  bonus  payments  are  scheduled 
to  occur  during  the  development  effort,  before  the  system  is  delivered.  Since  the  system 
isn’t  finished  yet,  it  can  be  difficult  to  detennine  if  the  contractor  has  really  done  the  kind 
of  exemplary  work  that  would  warrant  the  award  fee.  Someone  needs  to  have  the 
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technical  skill  to  evaluate  where  the  contractor  really  is  in  the  development  process  and 
whether  or  not  he  has  excelled  enough  to  earn  an  award. 

Translating  Between  The  End  User  And  The  Contractor.  The  IT  acquisition 
professional  has  one  foot  in  both  worlds.  He  understands  the  Army  and  the  needs  of  the 
Anny  customers.  He  should  have  the  technical  skill  and  experience  to  know  what  is  in 
the  realm  of  the  possible — what  can  likely  be  accomplished  given  the  terms  of  the 
contract  and  the  current  state  of  technology.  This  puts  him  in  the  unique  position  of  being 
able  to  translate  new  customer  requirements  into  “tech  speak”  for  the  contractor,  and 
explaining  technical  challenges  and  opportunities  to  the  customer  in  terms  that  can  be 
readily  understood. 

The  Need  for  the  IT  Acquisition  Leader 

Thus  far,  this  paper  has  focused  on  the  value  of  the  IT  professional  as  a  support 
staffer.  Similarly,  a  case  can  be  made  for  the  need  for  IT  acquisition  leaders  in  key 
program  management  and  program  executive  officer  positions.  Simply  put,  the  IT 
acquisition  leaders  need  to  be  developed.  They  need  training  and  extensive  experience 
that  is  significantly  different  from  their  non-IT  acquisition  counterparts. 

The  Anny  has  long  recognized  the  value  in  leaders  having  technical  experience 

relevant  to  the  organizations  they  lead.  For  example,  very  few  Medical  Service  Corps 

colonels  have  ever  been  assigned  command  of  a  Combat  Arms  Brigade,  and  few  Air 

Defense  Artillery  officers  have  been  assigned  to  command  logistics  units.  In  fact,  the 

need  for  relevant  experience  is  imbedded  in  our  doctrine.  Field  Manual  6-0  (Mission 

Command:  Command  and  Control  of  Anny  Forces)  specifically  notes  the  importance  of 

intuitive  decision  making,  which  it  defines  as: 

Intuitive  decision  making  is  the  act  of  reaching  a  conclusion  which  emphasizes 
pattern  recognition  based  on  knowledge,  judgment,  experience,  education, 
intelligence,  boldness,  perception,  and  character.47 

It  also  states: 

Clausewitz  described  intuition  as  ‘the  quick  recognition  of  a  truth  that  the  mind 
would  ordinarily  miss  or  would  perceive  only  after  long  study  and  reflection.47 
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The  manual  goes  on  to  state  that  this  kind  of  intuitive  decision  making  is 
especially  useful  when  time  is  short  or  infonnation  is  incomplete.  While  acquisition 
decisions  are  seldom  split-second  affairs,  they  are  often  made  with  incomplete 
information.  After  all,  the  whole  purpose  of  most  acquisition  programs  is  to  build 
something  that  has  never  been  built  before.  This  practically  guarantees  that  key  pieces  of 
information — how  long  it  will  take,  how  much  it  will  cost,  whether  or  not  the  latest 
changes  will  work  as  planned — are  unknown.  While  detailed  analysis  is  important  to 
making  good  system  development  decisions,  so  is  good  intuition.  An  experienced  IT 
acquisition  leader,  by  virtue  of  his  work  on  previous  IT  programs,  is  much  more  likely  to 
have  developed  that  kind  of  intuition. 

The  GAO  seems  to  agree.  In  a  report  on  problems  with  weapons  systems 
acquisition,  the  GAO  strongly  recommended  the  need  to  “strengthen  training  and  career 
paths  as  needed  to  ensure  program  managers  have  the  right  qualifications  to  manage  the 
programs  they  are  assigned  to.”  In  other  words,  it’s  not  enough  to  be  a  generically 
qualified  program  manager — one  also  needs  to  truly  understand  the  details  of  the  product 
one  is  responsible  for  developing.  In  the  same  way  that  it  makes  sense  to  use  personnel 
with  an  aviation  background  to  lead  aviation  programs,  it  makes  sense  to  use  IT 
personnel  to  lead  IT  programs. 

Without  the  good  intuition  that  comes  from  experience  with  IT  system 
development,  the  IT  program  manager  or  program  executive  officer  (PEO)  may  be  at  the 
mercy  of  his  staff  and  contractors;  he  will  not  be  able  to  effectively  judge  the  quality  of 
the  infonnation  they  are  providing  him  until  after  mistakes  are  made.  Given  the  hundreds 
of  millions  of  dollars  tied  up  in  Anny  IT  systems,  it  seems  wise  to  develop  and  assign 
experienced  leaders  to  avoid  these  kinds  of  costly  errors  in  judgment. 

Current  Challenges  in  Developing  the  Army  IT  Workforce 

Given  the  value  of  the  IT  acquisition  professional  to  the  Army,  it  seems 
appropriate  to  examine  how  well  the  Anny  is  doing  at  developing  and  utilizing  them. 
Analysis  reveals  much  room  for  improvement.  The  way  the  Army  manages  the 
workforce  is  confusing  and  segmented,  with  no  single  agency  responsible.  It  is  unclear 
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what  the  exact  duties  of  an  IT  acquisition  professional  should  be  should  be,  and  there  is  a 
shortage  of  technical  education  and  hands-on  IT  development  experience. 

Confusion  over  Workforce  Management  and  Slotting 

The  overlay  of  an  acquisition  personnel  management  structure  on  top  of  the 
existing  Anny/US  government  personnel  management  structure  has  resulted  in  some 
confusion  about  who  is  responsible  for  the  development  of  the  IT  acquisition 
professional.  There  are  many  agencies  involved,  but  no  single  authority  responsible  for 
ensuring  that  the  Army  has  the  correct  number  of  IT  acquisition  professionals,  or  that 
they  have  the  correct  skill  sets. 

The  Defense  Acquisition  Corps,  of  which  the  Anny  Acquisition  Corps  is  a  subset, 
had  identified  fifteen  different  acquisition  career  fields ,  from  contracting  officer  to 
program  manager.  Each  of  these  fields  has  certain  standards  of  training  and  experience 
that  are  supposed  to  be  met.  One  of  these  fields  is  entitled  “Information  Technology.” 


Table  I.  DoD  Acquisition  Career  Fields 


Career  Field 

Code 

Auditing 

U 

Business,  Cost  Estimating,  and  Financial  Management 

K 

Contracting 

C 

Facilities  Engineering 

F 

Industrial/Contract  Property  Management 

D 

Information  Technology 

R 

Life  Cycle  Logistics 

L 

Production,  Quality  &  Manufacturing — Production  &  Manufacturing 

G 

Production,  Quality  &  Manufacturing — Quality  Assurance 

H 

Program  Management 

A 

Purchasing 

E 

Systems  Planning,  Research,  Development  &  Engineering — Program  Systems  Engineer 

W 

Systems  Planning,  Research,  Development  &  Engineering — Science  &  Technology 
Manager 

I 

Systems  Planning,  Research,  Development  &  Engineering — Systems  Engineering 

s 

Test  &  Evaluation 

T 
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Military  and  civilian  acquisition  positions  in  the  Army  (and  DoD)  are  coded  for 
one,  and  only  one,  of  these  fifteen  career  fields.  This  sounds  straightforward,  but  in 
practice  is  very  complicated. 

Managing  IT  Acquisition  Civilians — Too  Many  Fingers  in  the  Pie 

For  Army  civilian  acquisition  professionals,  the  confusion  begins  because  every 
acquisition  civilian  employee  has  two  designations — a  standard  US  government 
occupational  series  and  an  acquisition  career  field.  In  some  cases,  these  two  designations 
correlate.  For  example,  all  acquisition  civilian  with  occupational  series  1102  (Contract 
Specialist)  are  required  to  be  certified,  or  working  towards  certification,  in  Acquisition 
Career  Field  C  (Contracting).49  But  Acquisition  Career  Field  R  (Infonnation  Technology) 
does  not  align  with  a  single  government  occupation  series.  In  fact,  the  IT  acquisition 
position  category  descriptions  published  by  DoD’s  Defense  Acquisition  University  lists 
10  separate  “typical”  occupational  series  that  might  work  in  the  Acquisition  Career  Field 
R  (Information  Technology).  These  include  certain  general  administrative  series, 
electronics  engineers,  general  business  and  industry  series,  operations  researchers, 
computer  scientists,  and  infonnation  technology  managers.50 

To  make  matters  even  more  complicated  to  manage,  some  of  these  same 
occupational  specialties  are  listed  as  “typical”  for  a  total  of  eight  of  the  other  fourteen 
acquisition  career  fields. 
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Table  II.  Applicable  Government  Occupational  Series  for 
Acquisition  Career  Field  “R”  (Information  Technology) 


Series 

Number 

Other  Acquisition  Career  Fields  for  this  Series 

Miscellaneous 
Administration  and 
Program 

0301 

Business,  Cost  Estimating,  and  Financial  Management, 
Life  Cycle  Logistics,  Production,  Quality  & 
Manufacturing — Production  &  Manufacturing, 

Management  and 
Program  Analysis 

0343 

Business,  Cost  Estimating,  and  Financial  Management, 
Life  Cycle  Logistics,  Program  Management 

Telecommunications 

0391 

General 

Telecommunications 

0392 

General  Engineering 

0801 

Business,  Cost  Estimating,  and  Financial  Management, 
Life  Cycle  Logistics,  Production,  Quality  & 
Manufacturing — Quality  Assurance,  Program 
Management,  Systems  Planning,  Research, 

Development  &  Engineering — Program  Systems 
Engineer,  Systems  Planning,  Research,  Development  & 
Engineering — Science  &  Technology  Manager,  Test  & 
Evaluation 

Electronics 

Engineering 

0855 

Business,  Cost  Estimating,  and  Financial  Management, 
Production,  Quality  &  Manufacturing — Quality 
Assurance,  Program  Management,  Systems  Planning, 
Research,  Development  &  Engineering — Program 
Systems  Engineer,  Development  &  Engineering — 
Science  &  Technology  Manager,  Test  &  Evaluation 

General  Business 
and  Industry 

1101 

Business,  Cost  Estimating,  and  Financial  Management, 
Life  Cycle  Logistics,  Program  Management 

Operations  Research 

1515 

Business,  Cost  Estimating,  and  Financial  Management, 
Life  Cycle  Logistics,  Production,  Quality  & 
Manufacturing — Quality  Assurance,  Program 
Management,  Systems  Planning,  Research, 

Development  &  Engineering — Program  Systems 
Engineer,  Development  &  Engineering — Science  & 
Technology  Manager 

Computer  Science 

1550 

Business,  Cost  Estimating,  and  Financial  Management, 
Systems  Planning,  Research,  Development  & 
Engineering — Program  Systems  Engineer, 

Development  &  Engineering — Science  &  Technology 
Manager 

Information 

Technology 

Management 

2210 

Test  &  Evaluation 

Because  different  agencies  are  responsible  for  the  development  of  different 
occupational  series  and  acquisition  career  field  personnel,  it  is  very  difficult  to  detennine 
who  is  actually  in  charge  of  the  IT  Acquisition  workforce. 
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By  means  of  Anny  Regulation  690-950,  the  Anny  has  grouped  all  civilian 
occupational  series  into  career  programs  (CP).  The  designated  functional  chief  of  each 
CP  is  responsible  for  training  and  educating  their  portion  of  the  workforce,  handling  any 
internship  program,  and  generally  looking  out  for  the  welfare  (i.e.,  size,  retention  and 
quality)  of  the  personnel  within  their  program  area.  One  challenge  is  that  the  typical 
series  for  listed  for  acquisition  IT  professionals  are  split  across  three  separate  career 
programs.  The  majority  of  the  IT  and  general  administrative  personnel  fall  in  CP  34, 
managed  by  the  Anny  CIO/G6;  the  computer  scientists  and  engineers  fall  under  CP  18, 
managed  by  Commander  of  the  US  Anny  Materiel  Command;  and  Series  1101  (General 
Business  and  Industry)  falls  under  CP  14,  managed  by  the  Assistant  Secretary  of  the 
Anny  for  Acquisition,  Logistics  and  Technology.51  The  Functional  Chief  of  each  CP  is 
responsible  for  the  career  management  of  all  civilians  with  those  occupational  series — 
both  non-acquisition  and  acquisition.  The  regulation  does  mention  the  Acquisition  Corps, 
but  it  doesn’t  explain  who  is  truly  responsible  for  the  acquisition  portion  of  the 
workforce. 

Managing  IT  Acquisition  Officers — Not  Being  Done 

The  military  side  of  Anny  IT  acquisition  is  a  bit  more  straightforward,  but  still 
confusing.  All  military  acquisition  personnel  are  managed  by  the  Acquisition  Branch  of 
the  Army  Human  Resources  Command.  Just  like  civilian  positions,  every  military 
acquisition  position  is  coded  to  a  particular  specialty,  with  the  code  (known  as  an  Area  of 
Concentration)  5 1R  used  for  IT  acquisition  positions.  However,  while  positions  are 
coded  for  IT  Acquisition,  the  officers  who  fill  these  positions  are  not.  In  the  latest  rewrite 
of  DA  Pamphlet  600-3,  which  governs  officer  career  management,  the  Area  of 
Concentration  of  5 1R  was  eliminated  and  all  officers  with  that  code  were  rolled  into  the 
5 1 A  (generic  program  manager)  Area  of  Concentration.  Because  of  this,  when  an 
organization  needs  someone  with  5 1R  experience,  personnel  managers  have  to  review 
available  officers’  files  to  ascertain  who  has  the  prerequisite  experience/acquisition 
certification.  Failing  that,  they  assign  someone  who  can  achieve  the  necessary 
certification  with  the  regulatory  requirement  of  24  months.  The  current  mindset  is  that 
acquisition  officers  need  to  be  well  rounded,  “agile  and  aggressive  leaders,”  rather  than 
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specialists.  The  emphasis  is  on  assigning  officers  to  all  the  different  fields  in  acquisition 
to  make  them  well-rounded,  rather  than  honing  their  skills  in  a  single  area  (like  IT) 
through  a  series  of  assignments.  As  a  result,  developing  military  IT  acquisition  officers 
is  a  hit-or-miss  proposal.  Hopefully,  the  Army  will  have  the  number  it  needs.  But  if  it 
does,  it  will  be  the  result  of  luck,  not  a  plan. 

The  Army  Acquisition  Support  Center — Involved,  But  Not  Responsible 

The  Army  does  have  an  organization  entitled  the  US  Anny  Acquisition  Support 
Center,  which  lists  amongst  its  duties,  to  “Plan,  program,  and  oversee/execute  career 
management  activities  for  the  AL&T  Workforce  (e.g.,  policies,  training,  opportunities, 
etc.).”  But,  as  discussed  earlier,  the  actual  management  of  the  workforce  is  the 
responsibility  of  many  other  agencies.  The  Support  Center  does  focus  on  providing 
training  opportunities  for  Anny  acquisition  personnel,  based  on  the  DoD  standards;  but  it 
is  not  staffed  to  act  as  a  proponent  for  the  various  career  fields.  As  of  this  writing,  no  one 
in  the  Support  Center  associated  with  the  support  of  the  IT  career  field  is  actually  an  IT 
acquisition  professional  themselves.  The  Support  Center  attempts  to  coordinate  the 
management  efforts  of  all  the  various  CP  functional  chiefs  and  the  Anny  Human 
Resources  Command,  who  by  regulation  actually  own  all  the  personnel.  But  none  of 
these  organizations  is  actually  chartered  to  develop  an  acquisition  workforce  either. 
Despite  the  hard  work  of  many  good  individuals,  the  cunent  setup  gives  no  one  both  the 
power  and  the  responsibility  to  develop  the  Anny’s  IT  Acquisition  workforce. 

No  One  is  Looking  Out  for  IT  Leaders 

There  is  one  additional  piece  of  confusion,  related  to  IT  acquisition  leaders.  Since 
all  acquisition  positions  have  to  be  coded  with  a  single  Career  Field  Designator,  all 
product/program  manager  positions  are  coded  “A”  (Program  Management).  They  are  not 
coded  as  IT  (“R”)  positions  at  all.  There  is  no  way,  given  the  current  system,  to  designate 
a  particular  program  manager  position  as  requiring  a  certified  IT  acquisition  professional. 
On  the  books,  a  person  is  either  a  program  manager  or  an  IT  professional — never  both. 
Within  the  Anny  Acquisition  Support  Center,  there  are  different  departments  responsible 
for  the  IT  field  and  the  program  manager  field;  So  even  if  all  these  CPs  weren’t  involved, 
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there  would  still  be  no  single  organization  looking  out  for  the  entire  IT  Acquisition 
workforce. 

Confusion  over  Duties 

In  light  of  Congress’s  concern  over  inherently  governmental  functions  and 
keeping  contractors  at  arm’s  length  from  those  functions,  it  makes  sense  for  the  Army  to 
have  clear  guidelines  as  to  what  tasks  it  expects  government  IT  acquisition  professionals 
to  perform.  This  would  be  helpful  not  only  to  justify  positions,  but  also  to  shape  the  kind 
of  training  and  experience  these  personnel  need.  It  would  help  in  determining  when  to 
use  a  government  IT  professional  for  a  task  and  when  to  use  a  contractor.  While  this 
paper  has  suggested  what  some  of  those  tasks  might  be,  the  fact  remains  that  there  is  no 
published  list  of  duties  for  IT  acquisition  professionals,  or  indeed  for  any  of  the 
acquisition  specialties. 

The  only  published  guidance  is  listed  in  the  IT  Career  Field  Position  Category 
Description,  which  states  that  IT  acquisition  professionals: 

•  Provide  direct  support  for  acquisitions  that  use  Information  Technology 
(IT),  including  National  Security  Systems. 

•  Apply  IT-related  laws,  policies,  directives,  and  provide  IT-related 
guidance  through  the  total  acquisition  life  cycle. 

•  Support  Global  Information  Grid  compliance  activities,  Information 
Assurance  certification  efforts,  Information  Support  Plan  preparation  in 
accordance  with  DoD  5000  and  800  series,  Chapter  7  of  the  Defense 
Acquisition  Guidebook  and  service-unique  information  management 
policies 

From  this  rather  vague  description,  one  could  describe  the  IT  acquisition  field  as 
primarily  Clinger-Cohen  Act  compliance,  sort  of  like  a  legal  advisor  to  make  sure  the 
program  meets  all  the  various  regulations  and  policies.  On  the  other  hand,  the  first  bullet, 
“Provide  direct  support...”  could  cover  a  myriad  of  technical  activities.  When  one  takes 
into  account  that  the  IT  career  field  can  include  electrical  engineers  and  computer 
scientists,  this  view  seems  more  likely.  One  hardly  needs  that  kind  of  technical  talent 
merely  to  oversee  policy  adherence. 
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But  when  it  comes  to  technical  IT  duties,  the  “Systems  Planning  Research  and 
Development — Program  Systems  Engineer”  career  field  may  come  into  play.  This  career 
field,  like  the  IT  field,  includes  computer  scientists  and  electrical  engineers.  And  in  fact, 
their  Career  Field  description  lists  many  of  the  tasks  suggested  in  this  paper,  such  as 
requirements  development  and  risk  management.  However,  this  career  field  also  includes 
almost  every  possible  kind  of  technical  expert  from  mechanical  engineers  to  biologists. 
While  a  rather  broad  category,  the  description  includes  such  relevant  activities  as  risk 
management  and  technical  assessment.  The  training  requirements  for  this  career  field  do 
allow  the  employee  to  take  some  electives  from  the  IT  track,  which  makes  it  useful.  But 
there  is  no  method  of  determining  whether  a  “systems  engineer”  is  an  IT  systems 
engineer,  an  aviation  systems  engineer,  or  perhaps  a  biological  systems  engineer.  The 
systems  engineer  career  field  is  incredibly  generic,  in  spite  of  the  very  different  functions 
we  would  expect  these  different  types  of  engineers  to  perfonn. 

There  is  simply  no  clear  guidance  that  maps  specific  acquisition  functions  to 
either  of  these  two  specialties.  And  without  that  level  of  detail,  it’s  difficult  to  ascertain 
just  how  many  IT  and  program  system  engineers  the  Anny  needs,  and  in  exactly  what 
skills  each  needs  to  be  trained. 

A  clear  example  of  the  confusion  lies  in  comparing  the  manpower  of  the  Anny’s 
two  primary  IT  PEOs — the  PEO  Command  Control,  Communications  Tactical  (PEO 
C3T)  and  the  PEO  Enterprise  Infonnation  Systems  (PEO  EIS).  PEO  C3T  has  over  100 
systems  engineers  and  only  about  20  IT  professionals.  PEO  EIS  has  over  100  IT 
professionals  and  only  two  systems  engineers!54  Yet  both  organizations  build  IT  systems. 
Which  one  is  staffed  correctly?  It’s  impossible  to  tell.  But  it  is  reasonable  to  assume  that 
some  IT  professionals  are  doing  systems  engineering  work,  while  some  systems 
engineers  are  doing  IT  work.  Better  guidance  is  needed. 

Not  Enough  Technical  Talent 

While  it  is  difficult  to  detennine  exactly  how  many  technical  personnel  the  Army 
needs,  there  do  not  seem  to  be  enough  of  them  to  go  around.  Within  the  IT  career  field, 
less  than  half  have  IT  or  computer-related  degrees.55  Less  than  a  third  has  any  form  of 
advanced  degree.  These  are  not  encouraging  numbers. 
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Why  so  few?  One  theory  is  that  the  pay  is  too  low.  A  college  student  with  an  IT 
degree  joining  the  Army  Acquisition  Corps  can  expect  to  make  around  $39,000  a  year  (a 
GS-7  salary)  in  the  Washington  DC  area.56  According  to  a  recent  survey  on  Dice.com,  a 
leading  career  website  for  technology  professionals,  that  same  student  could  make  in 
excess  of  $44,000  a  year  in  the  private  sector.  In  fact,  according  to  that  same  survey,  the 
average  IT  salary  in  the  DC  area  is  almost  $89,000. 57  And  that’s  just  the  average  salary — 
presumably  the  truly  talented  people  (the  same  ones  the  Anny  would  like  building  its 
systems)  make  much  more. 

Another  possibility  is  the  type  of  work  available.  Anny  acquisition  work  is 
primarily  oversight — evaluating  other’s  work — rather  than  doing  it  yourself.  While  there 
have  not  been  surveys  to  verify  this,  it  seems  plausible  that  many  computer  scientists  and 
engineers  want  to  use  their  skills  in  a  hands-on  sense — they  want  to  actually  build 
systems,  not  evaluate  and  guide  others  who  get  to  do  the  “real  work.” 

Whatever  the  reason  for  these  shortages,  weak  technical  skills  within  Anny  IT 
Program  Management  shops  can  only  mean  weak  oversight. 

Little  Practical  Experience 

Besides  having  issues  with  attracting  technical  expertise,  the  Army  Acquisition 
Corps  faces  challenges  in  developing  and  maintaining  that  technical  talent  once  a  person 
is  hired.  Since  acquisition  work  has  become  almost  entirely  oversight,  there  are  few 
places  for  the  newly  hired  IT  professional  to  build  technical  skills  by  actually  doing  the 
work. 

Take,  for  example,  the  newly  hired  computer  science  graduate  right  out  of 
college.  In  the  private  sector,  he  will  probably  go  to  work  as  a  programmer,  graduate  to 
system  designer,  and  then  perhaps  move  into  program  management  or  assignment  as  a 
lead  engineer.  By  the  time  he  is  put  in  a  leadership  position,  he  will  have  years  of 
practical  experience  to  help  him  make  smart  program  decisions. 

If  that  same  individual  joins  the  Anny  Acquisition  Corps,  he  goes  straight  into  an 
oversight  or  staff  role — reviewing  documents,  setting  schedules  and  budget,  etc. 

However,  his  technical  skills  never  really  have  the  chance  to  be  exercised  and  grow. 

Later  in  his  career,  when  he  gets  promoted  to  a  product  manager  or  lead  engineer 
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position,  he  will  still  have  the  technical  skills  of  a  brand  new  21 -year-old  college 
graduate — except  those  skills  are  now  a  decade  or  two  out  of  date,  and  may  have 
atrophied  immensely. 

A  study  of  IT  workers  in  the  private  sector  in  Great  Britain  supports  this  point. 
This  study,  conducted  for  the  British  Department  of  Trade  and  Industry,  warned  that  as 
companies  outsourced  technical  functions  to  companies  overseas,  they  eliminated  lower 
level  technical  jobs  (programmers,  call  center  employees,  etc.)  in  Great  Britain.  The 
problem  is  that  these  low  level  jobs  are  where  you  “grow”  personnel  to  assume  the  higher 
level  jobs  (project  managers,  solutions  architects,  account  managers)  that  companies  need 
to  oversee  the  outsourced  functions.  Without  access  to  graduates  of  these  entry-level  IT 
jobs,  companies  are  at  a  loss  as  to  where  to  hire  their  oversight  personnel.  So  instead, 
they  turn  to  hiring  oversight  personnel  away  from  the  competition,  a  practice  that  can 

c  o 

only  go  on  for  so  long  as  no  new  personnel  are  entering  the  job  pool.  It  is  easy  to  see 
the  parallel  to  Army  IT  acquisition — if  the  personnel  don’t  actually  build  anything 
themselves,  how  can  they  develop  the  technical  skills  needed  to  evaluate  others  who  are 
building  things? 

Years  ago  the  author  worked  at  the  National  Security  Agency  (NSA)  on  an 
information  security  program.  The  Division  Chief  was  an  engineer  of  great  talent.  He  had 
honed  his  skills  as  a  young  government  employee  working  on  the  team  that  actually  built 
the  prototype  of  the  STU-III  secure  telephone.  In  those  days,  the  NSA  did  much  of  its 
prototype  work  in-house  using  its  own  government  engineers.  His  early  career 
experiences  helped  him  as  a  leader.  His  technical  skills  at  assessing  risk  and  validating 
contractor-proposed  solutions  helped  all  his  division’s  programs  to  succeed.  But  like  the 
rest  of  the  government,  the  NSA  no  longer  does  as  much  in-house  development,  and  new 
engineers  don’t  get  to  build  security  devices  any  more.  As  a  result,  it  can  no  longer 
“grow”  leaders  like  this  Division  Chief.) 

There  are  places  within  the  Anny  Acquisition  Corps  where  personnel  can  do  real 
technical  work,  notably  the  laboratories  of  the  US  Anny  Research,  Development,  and 
Engineering  Command  (RDECOM).  But  there  is  no  program  in  place  to  get  the 
technically  experienced  personnel  out  of  the  labs  and  into  PM  shops,  and  no  easy  way  to 
rotate  newly  hired  PM  employees  through  the  labs  for  technical  refreshment. 
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Large  Workforce  Turnover  Ahead 

To  compound  the  workforce  problems  listed  above,  there  is  also  the  worry 
that  large  numbers  of  the  Army  IT  acquisition  workforce  may  be  retiring  soon. 

According  to  data  provided  by  the  Anny  Acquisition  Support  Center,  almost  a  third  of 
the  workforce  will  be  retirement  eligible  within  the  next  five  years. 55 

The  Big  Question 

Does  the  Army  have  enough  people  with  the  right  skills  to  do  the  Anny’s  IT 
development  work?”  The  answer  is — the  Army  doesn’t  know.  Neither  DoD  or  the  Anny 
has  clearly  identified  IT  acquisition  duties.  As  a  result,  it  cannot  be  detennined  if  the 
Anny  has  adequate  numbers  or  adequate  skills  to  perfonn  those  duties.  And  since  no  one 
organization  is  responsible  for  the  IT  workforce,  no  one  is  even  asking  the  question! 

Recommendations  for  the  Future 

If  the  Anny  wants  better  results  from  its  IT  programs,  and  if  it  wants  to  stay 
abreast  of  mounting  congressional  concern,  now  is  the  time  to  revitalize  the  IT 
Acquisition  workforce.  Based  on  the  issues  analyzed  in  this  paper,  the  following  are 
some  major  recommendations  to  consider. 

Centrally  Manage  the  Entire  IT  Acquisition  Workforce 

Put  the  career  management  of  all  IT  personnel,  including  engineers,  IT  program 
managers,  and  military  officers,  under  a  single  lead  agency.  This  would  help  the  Anny 
translate  the  duties  required  of  IT  acquisition  personnel  into  specific  training  and 
experience  requirements  which  could  be  used  to  develop  personnel  and  certify  their 
competency.  It  would  also  give  the  Anny  IT  Acquisition  workforce  a  single  proponent 
and  advocate — someone  who  is  responsible  for  ensuring  the  Army  has  enough  personnel 
with  the  right  skills  assigned  to  the  right  organizations. 

Possible  lead  agencies  include  the  Army  Acquisition  Support  Center  or  the  Army 
CIO/G6.  But  a  single  agency  needs  to  be  in  charge,  with  all  other  interested  parties  in 
support.  And  in  order  to  do  the  kind  of  research  and  planning  required,  the  responsible 
office  needs  to  have  human  resources  and  IT  acquisition  personnel  in  it. 
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On  the  civilian  side,  part  of  having  a  single  lead  agency  would  involve  providing 
all  IT  acquisition  personnel,  including  program  managers  and  system  engineers,  with 
some  additional  personnel  designation.  This  would  make  it  clear  who  is  an  IT  program 
manager  or  an  IT  systems  engineer,  as  opposed  to  non-IT  program  managers  and 
engineers.  Once  designated,  it  would  be  easy  for  a  single  agency  to  take  responsibility  for 
the  population. 

On  the  military  side,  this  would  involve  redesignating  some  officers  as  5 1R  (the 
old  code  for  Infonnation  Technology  Acquisition)  and  guiding  their  careers  accordingly. 
While  the  Army  may  need  well  rounded  officers  to  fill  many  of  its  senior  leader  ranks,  it 
should  not  be  blind  to  the  value  of  subject  matter  experts.  There  is  room  in  the  Anny  for 
an  IT  Acquisition  officer  career  ladder.  There  are  clear  IT  leadership  positions  up  to  the 
colonel  level.  There  are  even  general  officer  slots  that  could  benefit  by  being  filled  by  IT 
Acquisition  Officer,  such  as  the  leadership  of  PEO  Intelligence  and  Electronic  Warfare, 
and  PEO  Command  Control  Communications  Tactical.  Also,  while  the  position  of  PEO 
Enterprise  Infonnation  Systems  has  been  traditionally  filled  by  a  civilian,  there  is  no 
reason  that  a  qualified  IT  General  Officer  could  not  be  used  in  that  capacity.  Even  the 
position  of  Anny  CIO/G-6,  the  lead  IT  officer  in  the  entire  Anny  and  a  three-star  billett, 
is  designated  by  the  Anny  as  a  Critical  Acquisition  Position,  suggesting  that  it  could 
possibly  be  held  by  an  IT  acquisition  officer.  A  military  IT  acquisition  career  path  could 
develop  officers  towards  these  positions,  and  give  them  the  experience  they  need  to  truly 
excel  in  them. 

A  corollary  to  this  would  be  to  code  certain  leadership  positions  (e.g.,  program 
and  program  managers)  as  requiring  IT  career  field  certification  in  addition  to  pure 
program  management  career  certification.  This  would  ensure  these  key  positions  are 
filled  by  personnel  with  both  management  and  IT  training  and  experience. 

Determine  the  Duties  of  Army  IT  Acquisition  Professional 

The  Anny  Acquisition  Center,  in  cooperation  with  the  Defense  Acquisition 
University,  should  define  exactly  what  tasks  and  functions  personnel  in  the  IT  and  the  IT 
portion  of  the  Program  Systems  Engineer  Track  should  be  accomplishing.  This  would  not 
only  focus  training  and  guide  the  shaping  of  the  workforce;  it  would  help  build 
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appropriate  organizational  manpower  structures,  and  would  provide  clear  guidance  on 
where  the  use  of  in-house  contractors  is  appropriate.  In  light  of  Congress’s  recent  interest 
in  personal  service  contracts  described  earlier,  it  makes  sense  to  take  the  initiative  before 
a  solution  is  forced  upon  the  Army  from  above. 

Emphasize  Mid-Career  Hires 

Especially  in  a  down-turning  economy,  the  Anny  may  be  able  to  hire  competent 
IT  professionals  away  from  private  industry.  This  could  be  a  great  way  to  keep  current 
technical  skills  in  the  workforce,  and  to  leverage  the  hands-on  experience  one  gets  in  the 
private  sector.  But  special  attention  would  be  needed  to  green  these  new  hires.  They  may 
understand  IT,  but  they  probably  don’t  understand  the  Army  and  its  customers.  In  the 
same  way  that  we  have  rotation  programs  for  interns  today,  the  Anny  should  fund  a 
program  to  orient  mid  career  hires  not  only  to  their  own  organization,  but  to  the  Anny 
they  serve. 

Create  a  Technical  Career  Track 

Not  all  engineers  want  to  manage,  but  most  want  to  advance.  The  Anny  should 
establish  a  clear  career  path  for  qualified  technical  personnel,  for  example  going  from 
program  engineer  to  lead  systems  engineer  to  technical  director  at  higher  grade  levels. 
Using  the  model  of  the  NCO  chain  in  the  unifonned  Army,  the  Anny  could  establish 
technical  directors  at  each  level  of  the  hierarchy  who  would  advise  the  program 
leadership  on  technical  matters,  and  directly  coordinate  with  lower  level  technical 
leadership  to  resolve  issues.  This  should  increase  retention,  highlight  the  value  of  real 
technical  oversight,  and  provide  key  technical  staff  support  to  decision  makers. 

Consider  Technical  Rotations 

While  the  Army  does  not  have  the  kind  of  assignment  authority  over  civilians  that 
it  has  over  unifonned  acquisition  workers,  it  could  still  develop  a  program  for  technical 
rotations,  where  an  engineer  leaves  the  PM  shop  and  goes  to  work  in  a  Anny  lab  doing 
real  technical  work.  A  one  or  two  year  tour  every  ten  years  could  help  keep  our  oversight 
personnel  current  and  savvy,  and  may  help  with  recruiting  personnel  who  enjoy  hands-on 
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technical  work  or  are  worried  about  losing  their  skills.  The  Anny  could  provide  bonuses 
for  such  rotations,  or  make  them  a  prerequisite  for  certain  positions. 

This  might  involve  partnerships  with  non-PEO  organizations  that  are  co-located  at 
the  same  installation.  This  fits  in  nicely  with  the  current  trend  of  combining  PEO  and 
Army  Materiel  Command  units  into  integrated  Lifecycle  Commands .  It  also  might  be 
useful  for  PEOs  to  consider  keeping  a  certain  amount  of  work  in-house  specifically  for 
professional  development.  A  PEO  could  choose  one  or  two  smaller  development 
programs  and  use  his  government  personnel  to  develop  the  prototype  before  relying  on 
contractors.  In  this  way,  he  could  continually  hone  the  skills  of  his  technical  workforce. 

Conclusion 

This  paper  has  attempted  to  make  the  case  that  IT  oversight  is  critical  to  Army 
acquisition.  This  oversight  can  be  improved  by  acknowledging  its  unique  characteristics 
and  growing  a  force  of  experts  to  guide  our  systems  through  the  various  stages  of 
development  and  into  the  hands  of  the  soldiers  and  civilians  who  make  the  Army  run. 

The  acquisition  community  owes  the  Army  world-class  IT  systems.  It  will  take  well 
trained  and  experienced  Army  IT  professionals  to  make  this  happen. 
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